Skip to content

fix: repair invalid LLM JSON escapes + retry on parse failure#67

Merged
ajianaz merged 1 commit into
developfrom
fix/llm-json-repair-retry
Jun 1, 2026
Merged

fix: repair invalid LLM JSON escapes + retry on parse failure#67
ajianaz merged 1 commit into
developfrom
fix/llm-json-repair-retry

Conversation

@ajianaz

@ajianaz ajianaz commented Jun 1, 2026

Copy link
Copy Markdown
Collaborator

Problem

LLM (glm-5.1) sometimes produces JSON with invalid escape sequences (e.g. \s, \d) causing serde_json strict parse to fail with invalid escape at line N column M. This results in:

  1. Cora exits with code 1
  2. SARIF output is empty
  3. CI posts "No issues found" — false negative (no actual review happened)

Fix

1. JSON Repair (repair_invalid_escapes)

  • State machine that walks through JSON string literals
  • Doubles backslash before non-standard escape chars (e.g. \s\\s)
  • Preserves valid escapes (\n, \t, \", \\, \uXXXX)
  • Applied before serde_json::from_str in both parse_review_response and parse_scan_response

2. Retry on Parse Failure (review_diff)

  • If first parse attempt fails, retry LLM call once
  • Second attempt usually produces valid JSON
  • Total: repair first → if still fails → retry → repair again

3. Tests (5 new)

  • Valid JSON unchanged
  • Invalid \s+ escape repaired
  • Invalid \uGGGG unicode escape repaired
  • Valid escapes preserved
  • End-to-end parse with invalid escapes succeeds

Files Changed

  • src/engine/llm.rs: +186 lines (repair function + retry + tests)

@coderabbitai

coderabbitai Bot commented Jun 1, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@ajianaz, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 28 minutes and 34 seconds. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 6acc8f16-e21c-4c5c-b510-aee9d524c589

📥 Commits

Reviewing files that changed from the base of the PR and between 1b97a79 and e12e630.

📒 Files selected for processing (1)
  • src/engine/llm.rs
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/llm-json-repair-retry

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@ajianaz
ajianaz force-pushed the fix/llm-json-repair-retry branch from 81a9a48 to e12e630 Compare June 1, 2026 04:01
@github-actions

github-actions Bot commented Jun 1, 2026

Copy link
Copy Markdown

🔍 Cora AI Code Review

Blocked — critical issues found.

🔴 Error (2)

  • src/engine/llm.rs:224 — In the Err(e) branch, if the retry also fails to parse (parse_review_response(&retry_raw)?), the error message will be confusing — it says the LLM response is invalid JSON but gives no indication this was a retry. The original parse error context is lost. Consider wrapping the second parse error with context indicating it was a retry attempt.
  • src/engine/llm.rs:560 — When next == 'u', the code consumes exactly 4 hex digits. But if those hex digits are fewer than 4 (e.g., \uGG), it silently consumes whatever hex digits exist and continues. The is_valid_json_escape function returns true for 'u', so \uGGGG is treated as a valid escape start, but then the 4-char hex loop finds non-hex chars and skips them — producing \u followed by GGGG which is still invalid JSON. The logic is inconsistent: \u is marked valid but the hex validation is incomplete.

Review powered by cora-cli · BYOK · MIT

@ajianaz
ajianaz merged commit 7b343a1 into develop Jun 1, 2026
8 checks passed
@ajianaz
ajianaz deleted the fix/llm-json-repair-retry branch June 1, 2026 04:06
ajianaz added a commit that referenced this pull request Jul 16, 2026
* perf: resolve scan/review pipeline performance bottlenecks (P2)

Fix 10 performance issues — all 'repeated work in loops' patterns:

#41 - Pre-compile regex patterns once per rule instead of per line
#5  - Batch DB queries in handle_find_affected_tests (single IN clause)
#13 - Batch symbol fetch for Affected command (single query)
#14 - Prepare SQL statement once outside test-pattern loop
#59 - Early cutoff in secrets scanner when max_findings reached
#70 - Break out of all loops when symbol cap hit per file
#67 - Cache file reads during sibling search in resolver
#3  - Reuse single Tokio runtime for MCP tool calls (static LazyLock)
#22 - Static LazyLock regexes in detect_function_entry
#24 - Single transaction for prune_deleted instead of per-file

Refs #335

* fix(ci): resolve clippy + security audit failures

- clippy: remove redundant borrow in format! arg (llm.rs:456 &user_prompt)
- security: bump anyhow 1.0.102 -> 1.0.103 (RUSTSEC-2026-0190, downcast_mut unsoundness)
- security: bump crossbeam-epoch 0.9.18 -> 0.9.20 (RUSTSEC-2026-0204, fmt::Pointer null deref)

Refs #335

---------

Co-authored-by: ajianaz <ajianaz@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant